• 菜雞行為：把程式碼交出去當成已經交付
• STAR 階段：A+R (Action + Result)
• 本篇定位：交代如何用最小文件與證據讓成果可驗收、可接手、可回復。

這個系列會用 STAR 架構整理每一段職場故事。STAR 分別代表情境（Situation）、任務（Task）、行動（Action）與結果（Result）。每個故事會拆成三天：第一天談 S，還原當時的情境與我原本的理解；第二天談 T，釐清真正的任務、限制與完成條件；第三天則合併 A 與 R，整理我採取的行動、造成的結果，以及後來學到的事。

這篇在三日故事中的位置

Day 23｜一次交付還欠哪些文件、限制和回復方式，把任務定成讓接手者不靠我就能操作、驗證、部署與回復。本篇交代做法、結果與方法的限制。

從接手者的第一週反推，而不是從文件清單

我沒有從「該寫哪些文件」開始。在虛構的粉鳥工單服務裡，我假想接手逾期提醒排程的人的第一週：看懂改了什麼、自己啟動、驗證功能、失敗時退回。每個動作缺什麼資訊，我就補什麼，順序照這條時間軸排；接手者第一週用不到的內容，一律不寫。

一份入口，而不是一疊文件

寫的時候我只堅持一件事：所有內容收進同一份入口文件，從變更摘要、啟動順序、驗證方式、已知限制到部署與回復步驟；細節可放在連得到的位置，但入口只有一份。回復步驟我先照文件演練一次，演練不過就改文件，不改記憶。未完成事項照實列在文末。

接手不必考古，但文件從完成那天開始過期

結果是質性的，我不補數字。可支持的改變有三個：接手者能照文件啟動與驗證，不必把我的訊息視窗當客服台；驗收有固定入口，檢查的是文件與證據，不是我的記憶；我日後回來改功能，不必重新考古。限制同樣真實：證據包在完成那天就開始過期，功能一改、文件沒跟上，就會反過來誤導人；它也擋不住架構層級的知識斷層。維護它的成本是交付的一部分，不是好心。

粉鳥工程筆記：入口只有一份，而且會過期

內容與順序由接手者的工作反推；入口只有一份；回復步驟演練過才算存在；交付包含維護文件的責任。

今天可以帶走的練習

替一項小功能花一小時，用《交付證據包》整理變更、操作、測試、限制、部署與回復，收進同一份文件。產出是一至兩頁的證據包，驗收是請另一位讀者只看文件完成一次啟動或驗收，卡住的地方就是待補項目。當天能口頭交接的小修改不必建包。

對應工具：《交付證據包》。

# 交付證據包

用途：把變更、操作、測試、限制、部署與回復收進同一份交付入口。
使用時機：成果要交給沒跟過開發的人驗收或維護時。
不必使用：小修改當天能口頭交接、風險很低時。

| 項目 | 內容 | 驗收者 |
| --- | --- | --- |
| 變更摘要 | 改了什麼、為什麼改 | 讀者能重述目的 |
| 操作與驗證 | 啟動步驟、如何確認成功 | 不問作者能啟動 |
| 限制與未完成 | 已知問題與不適用情境 | 與實際行為相符 |
| 部署與回復 | 上線步驟、失敗怎麼退回 | 回復演練通過 |

提醒：入口只有一份；文件會過期，接手後要繼續維護。

下一篇

交付不再等於丟出程式碼。但下一種學生味更深：這些動作做過很多次後，我會不會只是熟練地重複？Day 25｜做過很多次，我還是可能只是在重複熟悉動作，開始最後一組故事。